home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 98 / Skunkware 98.iso / src / net / bind-contrib.tar.gz / bind-contrib.tar / contrib / multizdb / MULTIZDB next >
Encoding:
Text File  |  1996-10-25  |  3.0 KB  |  69 lines
  1. Sun Jul 24 18:07:09 EDT 1994
  2. ----------------
  3. This kit consists of the following files:
  4.  
  5.     MULTIZDB          this file
  6.     MZDB.patch        a patch file
  7.     ns_init.c         complete replacement for nslookup/ns_init.c
  8.  
  9. (I included a new version of ns_init.c since it was dramatically
  10. rearranged.  There isn't that much new functionality there, but lots
  11. of old things were done in ways inconvenient for this extension.)
  12. ns_init.c and the patches are based on BIND 4.9.3-beta-9.  Sorry in
  13. advance for the difference in code indent style, but somebody can run
  14. it through a beautifier later.
  15.  
  16. The patch enables MULTIZDB by default, but it has no effect unless you
  17. put "multizone" directives in your named.boot file.
  18. ----------------
  19.  
  20.  
  21. This is a description of the Multizone Database File (MULTIZDB)
  22. extension for BIND.  The overall feature is controlled via an option;
  23. to enable it, define MULTIZDB in "conf/options.h".
  24.  
  25. MULTIZDB allows you to put records from more than one zone in a single
  26. database file.  For some scenarios, this can simplify database
  27. maintenance, and, by simplifying it, make it less error-prone.  The
  28. MULTIZDB extension affects only the local storage format of the zone
  29. files.  It does not affect any DNS protocol elements nor does it alter
  30. any algorithm by which BIND arrives at an answer.
  31.  
  32. A simple example is that of a DNS administrator who happens to have
  33. authority for a subdomain and a Class C network address, and where the
  34. two happen to be well-aligned.  The standard way to operate BIND for
  35. this case would be to have two database files.  First, for the forward
  36. zone, e.g., buzz.bomb.org ==> db.buzz.  Second, for the reverse
  37. mapping zone, e.g., 23.45.201.in-addr.arpa ==> db.201.445.23.
  38. Whenever an endpoint is added, deleted, or changed, both database
  39. files must be updated.  With MULTIZDB, both zones could be kept in a
  40. single file, making it more likely that both halves of an update would
  41. be done in synch.
  42.  
  43. A new keyword, multizone, is recognized for named.boot.  It takes as
  44. its single argument the name of the file containing the resource
  45. records.  Like other directives in named.boot, the filename is
  46. relative to the assumed directory.
  47.  
  48. A handful of new $ directives are recognized inside a multizone
  49. database file:
  50.  
  51.     $primary
  52.     $secondary
  53.     $stub
  54.     $cache
  55.  
  56. These are like the similarly-named directives from the named.boot
  57. file.  For $primary, if a database file is named, it is ignored.
  58. ($secondary, $stub, and $cache are provided primarily for completeness
  59. since in most scenarios there is no real win in putting that
  60. information in a multizone database file instead of in named.boot.)
  61. These directives demark zones inside the multizone database file.
  62. Logically, it's as if the reading of a new file were begun at that
  63. point.  Multizone database files do not nest and may not contain
  64. $include directives.
  65. -- 
  66.   Bill@attmail.com                    billc@pegasus.ATT.COM    or
  67.   +1 908 576 2932, Fax x4473          William_J_Carpenter@ATT.COM
  68.   AT&T Bell Labs / AT&T EasyLink Services               LZ 3C-207
  69.